Order risk management for derivative products

ABSTRACT

Systems and methods are provided for processing derivative product orders at an exchange. Traders provide derivative product order risk data to the exchange. The order risk data may include maximum delta, gamma and/or vega utilization values for derivative product contracts based on the same underlying product. Before executing a trade, a match system analyzes the trader&#39;s current utilization state and the utilization that would result after the trade. The match system may then execute all or a portion of the trade.

The present application is a continuation patent application of U.S.patent application Ser. No. 13/182,178, filed Jul. 13, 2011, which is acontinuation patent application of U.S. patent application Ser. No.11/951,891, filed Dec. 6, 2007, which is a divisional of U.S. patentapplication Ser. No. 10/676,318, filed Oct. 1, 2003, which is acontinuation-in-part of U.S. patent application Ser. No. 10/611,458,filed Jul. 1, 2003, which is a continuation-in-part of U.S. patentapplication Ser. No. 10/385,152, filed Mar. 10, 2003. The entiredisclosures of all priority applications are hereby incorporated byreference.

FIELD OF THE INVENTION

The present invention relates to derivative product trading methods andsystems and, in particular, to methods and systems that utilize orderrisk data.

DESCRIPTION OF THE RELATED ART

Computer systems and networks increasingly are being used to tradesecurities and derivative products. Computer systems and networksprovide several advantages when compared to manual methods of trading.Such advantages include increased accuracy, reduced labor costs and theability to quickly disseminate market information.

Options are frequently traded via computer systems. An option may beused to hedge risks by allowing parties to agree on a price for apurchase or sale of another instrument that will take place at a latertime. One type of option is a call option. A call option gives thepurchaser of the option the right, but not the obligation, to buy aparticular asset either at or before a specified later time at aguaranteed price. The guaranteed price is sometimes referred to as thestrike or exercise price. Another type of option is a put option. A putoption gives the purchaser of the option the right, but not theobligation, to sell a particular asset at a later time at the strikeprice. In either instance, the seller of the call or put option can beobligated to perform the associated transactions if the purchaserchooses to exercise its option or upon the expiration of the option.

Traders typically use theoretical models to determine the prices atwhich they will offer to buy and sell options. The theoretical optionpricing models often produce values that reflect an option's sensitivityto changes in predefined variables. These predefined variables areassigned Greek letters, such as delta, gamma, theta, and vega. Delta isa measure of the rate of change in an option's theoretical value for aone-unit change in the price of the option's underlying contract. Thus,delta is the theoretical amount by which the option price can beexpected to change for a change in the price of the underlying contract.As such, delta provides a local measure of the equivalent position riskof an option position with respect to a position in the underlyingcontract. A “50 Delta” option should change its price 50/100, or ½ apoint, for a one point move in its underlying contract.

Gamma is a measure of the rate of change in an option's delta for aone-unit change in the price of the underlying contract. Gamma expresseshow much the option's delta should theoretically change for a one-unitchange in the price of the underlying contract. Theta is a measure ofthe rate of change in an option's theoretical value for a one-unitchange in time to the option's expiration date. Vega is a measure of therate of change in an option's theoretical value for a one-unit change inthe volatility of the underlying contract. Delta, gamma, and vega arethe primary risk management measures used by those who trade in options.

A single option order typically identifies the underlying security, theexpiration date, whether the option is a call or a put, the strike priceand all other standard order terms (e.g. buy/sell, quantity, accountnumber etc.). Each time the price of the underlying contract changes orone of the variables in the trader's theoretical model changes, a tradermay cancel all of the relevant orders, recalculate new order prices andtransmit new order prices to the exchange.

Computer implemented systems for trading derivative products canincrease a market maker's price exposure. In the open outcrymarketplace, a market maker makes markets in strikes/spreads in a serialprocess. As a result, the market maker is never at risk of having morethan one of their prices acted upon simultaneously. In contrast,computer implemented systems allow market makers to provide bid/askspreads for several strikes and spreads simultaneously. The parallelprice exposure in the electronic options marketplace can pose a risk tothe market maker in that they can quickly accumulate a large riskposition before they can cancel/modify their resting orders. This typeprice exposure is known as in-flight fill risk.

Existing attempts to protect against in-flight fill risks have resultedin reduced market making participation and corresponding detrimentalaffects on liquidity, trading volume and price discovery.

Therefore, there is a need in the art for improved derivative producttrading methods and systems that allow traders to protect againstin-flight fill risks.

SUMMARY OF THE INVENTION

The present invention overcomes problems and limitations of the priorart by providing trading methods and systems that utilize order riskdata provided by traders. The order risk data includes order riskparameters, such as maximum delta, gamma and/or vega utilization valuesfor derivative product contracts based on the same underlying product. Amatch system may then limit the trader's in-flight fill risks bytracking the trader's current order risk parameter utilization state andanalyzing potential trades to determine how those trades will impact thetrader's order risk parameter utilization state. The match system mayalso limit cumulative risks by canceling orders after an order riskparameter utilization state has been exceeded.

In one embodiment, advantages of aspects of the present invention areprovided by a method of processing derivative product orders at anexchange. The method includes receiving derivative product order riskdata including at least one threshold value corresponding to at leastone order risk parameter. An order for a derivative product is receivedfrom a trader. As used herein “trader” includes a customer submitting anorder and is not limited to mean a professional trader. The derivativeproduct order and a trader's current order risk utilization state areutilized to calculate utilization data. Next, the derivative productorder is processed in a manner determined by the derivative productorder risk data and the utilization data.

In another embodiment, advantages of aspects of the present inventionare provided by a method of processing derivative product orders at anexchange. The method includes receiving derivative product order riskdata including at least one threshold value corresponding to at leastone order risk parameter. An order for a derivative product is receivedfrom a trader. A trader's current order risk parameter utilization valueis then determined. Next, the derivative product order is executed whenthe trader's current order risk parameter utilization value does notexceed the threshold value.

In yet another embodiment advantages of aspects of the present inventionare provided by a method of managing risks associated with derivativeproduct orders placed at a plurality of exchanges. The method includestransmitting to a first exchange first derivative product order riskdata including at least one threshold value corresponding to at leastone order risk parameter. Second derivative product order risk dataincluding at least one threshold value corresponding to the at least oneorder risk parameter is transmitted to a second exchange. Next, atrader's current order risk utilization states at the first exchange andat the second exchange are determined The determination may then be usedto transmit to the first or second exchange an offset value to adjustthe order risk parameter.

In other embodiments, the present invention can be partially or whollyimplemented on a computer-readable medium, for example, by storingcomputer-executable instructions or modules, or by utilizingcomputer-readable data structures.

Of course, the methods and systems of the above-referenced embodimentsmay also include other additional elements, steps, computer-executableinstructions, or computer-readable data structures. In this regard,other embodiments are disclosed and claimed herein as well.

The details of these and other embodiments of the present invention areset forth in the accompanying drawings and the description below. Otherfeatures and advantages of the invention will be apparent from thedescription and drawings, and from the claims.

BRIEF DESCRIPTION OF THE DRAWINGS

The present invention may take physical form in certain parts and steps,embodiments of which will be described in detail in the followingdescription and illustrated in the accompanying drawings that form apart hereof, wherein:

FIG. 1 shows a computer network system that may be used to implementaspects of the present invention;

FIG. 2 illustrates a system in which traders exchange information with amatch system, in accordance with an embodiment of the invention;

FIG. 3 illustrates an order risk management module in accordance with anembodiment of the invention;

FIG. 4 illustrates a method of processing derivative product orders atan exchange, in accordance with an embodiment of the invention;

FIG. 5 illustrates a variable defined derivative product order inaccordance with an embodiment of the invention;

FIG. 6 illustrates a method of processing variable defined derivativeproduct orders by an exchange computer, in accordance with an embodimentof the invention; and

FIG. 7 illustrates a front-end system that may be used to manage risksassociated with derivative product orders placed at a plurality ofexchanges.

DETAILED DESCRIPTION OF THE INVENTION

Aspects of the present invention are preferably implemented withcomputer devices and computer networks that allow users to exchangetrading information. An exemplary trading network environment forimplementing trading systems and methods is shown in FIG. 1. An exchangecomputer system 100 receives orders and transmits market data related toorders and trades to users. Exchange computer system 100 may beimplemented with one or more mainframe, desktop or other computers. Auser database 102 includes information identifying traders and otherusers of exchange computer system 100. Data may include user names andpasswords potentially with other information to identify users uniquelyor collectively. An account data module 104 may process accountinformation that may be used during trades. A match engine module 106 isincluded to match bid and offer prices. Match engine module 106 may beimplemented with software that executes one or more algorithms formatching bids and offers. A trade database 108 may be included to storeinformation identifying trades and descriptions of trades. Inparticular, a trade database may store information identifying the timethat a trade took place and the contract price. An order book module 110may be included to compute or otherwise determine current bid and offerprices. A market data module 112 may be included to collect market dataand prepare the data for transmission to users. A risk management module134 may be included to compute and determine a user's risk utilizationin relation to the user's defined risk thresholds. An order processingmodule 136 may be included to decompose variable defined derivativeproduct and aggregate order types for processing by order book module110 and match engine module 106.

The trading network environment shown in FIG. 1 includes computerdevices 114, 116, 118, 120 and 122. Each computer device includes acentral processor that controls the overall operation of the computerand a system bus that connects the central processor to one or moreconventional components, such as a network card or modem. Each computerdevice may also include a variety of interface units and drives forreading and writing data or files. Depending on the type of computerdevice, a user can interact with the computer with a keyboard, pointingdevice, microphone, pen device or other input device.

Computer device 114 is shown directly connected to exchange computersystem 100. Exchange computer system 100 and computer device 114 may beconnected via a T1 line, a common local area network (LAN) or othermechanism for connecting computer devices. Computer device 114 is shownconnected to a radio 132. The user of radio 132 may be a trader orexchange employee. The radio user may transmit orders or otherinformation to a user of computer device 114. The user of computerdevice 114 may then transmit the trade or other information to exchangecomputer system 100.

Computer devices 116 and 118 are coupled to a LAN 124. LAN 124 may haveone or more of the well-known LAN topologies and may use a variety ofdifferent protocols, such as Ethernet. Computers 116 and 118 maycommunicate with each other and other computers and devices connected toLAN 124. Computers and other devices may be connected to LAN 124 viatwisted pair wires, coaxial cable, fiber optics or other media.Alternatively, a wireless personal digital assistant device (PDA) 122may communicate with LAN 124 or the Internet 126 via radio waves. PDA122 may also communicate with exchange computer system 100 via aconventional wireless hub 128. As used herein, a PDA includes mobiletelephones and other wireless devices that communicate with a networkvia radio waves.

FIG. 1 also shows LAN 124 connected to the Internet 126. LAN 124 mayinclude a router to connect LAN 124 to the Internet 126. Computer device120 is shown connected directly to the Internet 126. The connection maybe via a modem, DSL line, satellite dish or any other device forconnecting a computer device to the Internet.

One or more market makers 130 may maintain a market by providing bid andoffer prices for a derivative or security to exchange computer system100. Exchange computer system 100 may also exchange information withother trade engines, such as trade engine 138. One skilled in the artwill appreciate that numerous additional computers and systems may becoupled to exchange computer system 100. Such computers and systems mayinclude clearing, regulatory and fee systems. Coupling can be direct asdescribed or any other method described herein.

The operations of computer devices and systems shown in FIG. 1 may becontrolled by computer-executable instructions stored on acomputer-readable medium. For example, computer device 116 may includecomputer-executable instructions for receiving order information from auser and transmitting that order information to exchange computer system100. In another example, computer device 118 may includecomputer-executable instructions for receiving market data from exchangecomputer system 100 and displaying that information to a user.

Of course, numerous additional servers, computers, handheld devices,personal digital assistants, telephones and other devices may also beconnected to exchange computer system 100. Moreover, one skilled in theart will appreciate that the topology shown in FIG. 1 is merely anexample and that the components shown in FIG. 1 may be connected bynumerous alternative topologies.

FIG. 2 illustrates a system in which traders 202 and 204 exchangeinformation with a match system 206, in accordance with an embodiment ofthe invention. Trader 202 is shown transmitting a variable definedderivative product order 208 and order risk data 210 to match system206. Variable defined derivative product order 208 includes theidentification of a derivative product and a variable order price.Variable defined derivative product orders are described in greaterdetail below in connection with FIG. 3. Order risk data 210 may act as athrottle to limit the number of transactions entered into by trader 202.Order risk data may include maximum and minimum values of delta, gammaand vega to utilize over a given period of time, such as a trading day.Trader 204 transmits derivative product orders 212 and 216 to matchsystem 206. Each trader may transmit several derivative product ordersand may associate order risk data with one or more of the derivativeproduct orders. As shown in order 212, one or more of the orders mayinclude the identification of a hedge transaction.

Match system 206 may include several modules for determining prices,matching orders and executing transactions. An order book module 218 maybe included to maintain a listing of current bid and offer prices. Aprice calculation module 220 calculates order prices based on pricedetermination variables provided as part of variable defined derivativeproduct orders. Price calculation module 220 may also calculate orderprices based on formulas received from traders. For example, derivativeproduct order 208 may include a formula that is a function of anunderlying contract, delta and gamma Price calculation module 220 may beconfigured to calculate an order price every time the price of theunderlying contract changes.

Price calculation module 220 may use a default formula with pricedetermination variable values supplied by a trader. In one embodiment,the change in a derivative product price is equal to a second orderTaylor series expansion, such as:ChgUnderlyingPrice*delta+(½(ChgUnderlyingPrice^2*gamma))  (1)wherein ChgUnderlyingPrice is the change in the underlying price. Atrader would supply price determination variables delta and gamma andprice calculation module would track the derivative product price as theunderlying contract changes.

A formula database 224 may be included to store derivative product orderformulas. The formulas may be provided by traders or may be standardformulas provided by an exchange. A market data module 226 may be usedto collect and disseminate market data. A match engine module 228matches bid and offer prices. Match engine module 228 may be implementedwith software that executes one or more algorithms for matching bids andoffers.

A hedge module 230 may be included to perform hedge transactions basedon derivative product transactions. In one embodiment of the invention,hedge module 230 conducts transactions with a trading engine or matchsystem other than match system 206. Hedge module 230 may also performsome or all of the function of risk management module 134 (shown in FIG.1). Exemplary hedge transactions are described in detail below withreferences to FIGS. 6 and 7.

An order processing module 236 may be included to decompose variabledefined derivative product and bulk order types for processing by orderbook module 218 and match engine module 228. A controller 232 may beincluded to control the overall operation of the components showncoupled to bus 234. Controller 232 may be implemented with a centralprocessing unit.

An order risk management module 222 is included to limit as in-flightfill risks. For example, trader 202 provided maximum and minimum delta,gamma and vega utilization values to match system 206. Those values maybe stored in order risk management module 222 and tracked and computedbefore executing transactions.

FIG. 3 illustrates an order risk management module 302 in accordancewith an embodiment of the invention. A database 304 stores order riskparameter settings. Column 304 b, for example, includes deltautilization threshold values. Delta utilization threshold values may beincluded in order risk data 210 that is transmitted from trader 202 tomatch system 206. Database 304 may also include the current state oforder risk parameters. Column 304 c, for example, includes the currentdelta utilization state for the entities listed in column 304 a. Thecurrent utilization state of an order risk parameter is calculated byadding together the utilization values of the order risk parameter fromprevious trades. For example, if a trader is involved in two tradeshaving individual delta utilization values of +45 and +60, after thesecond trade is executed, the trader's delta utilization state would beequal to +105.

Database 304 shows an embodiment in which several levels of order riskparameters may be used. For example, firm A has offices X and Y andemploys traders 1-4. Trader 1 is obligated to comply with the order riskparameters for himself, office X and firm A. Providing order riskparameter settings in a hierarchal manner allows entities to allocaterisks among subordinate entities.

Order risk management module 302 may also include a calculation module306 for calculate order risk parameter values. An offset module 308 maybe used to process offset values received from traders. An offset valuemay be used to provide an adjustment to an order risk parameterthreshold value. For example, firm A can increase its delta utilizationthreshold to 220 by providing an offset value of 20. In one embodimentof the invention, an entity may allow subordinate entities to provideoffset values and place limits on the use of offsets. Match system 206may also be configured to regulate the use of offsets.

FIG. 4 illustrates a method of processing derivative product orders atan exchange, in accordance with an embodiment of the invention. In step402 a matching system receives derivative product order risk dataincluding at least one threshold value corresponding to lease one orderrisk parameter. Step 402 may include receiving order risk data 210.Next, the match system receives an order for a derivative product from atrader in step 404. Step 404 may include receiving a variable definedderivative product order, as has been described above. In step 406, thematch system utilizes the derivative product order and a trader'scurrent order risk utilization state to calculate utilization data. Insome embodiments of the invention, step 406 may include applying theutilization of a hedge transaction that accompanies a derivative productorder so that the utilization data accounts for the hedge transaction.Of course, when the trader is a subordinate entity, step 406 may includeutilizing the current order risk utilization state of one or moreadditional entities. For example, with respect to FIG. 3, when analyzingtrader 1's current utilization state, the utilization states of office Xand firm A should also be analyzed. This is because trader 1 may bebelow his utilization threshold, but office X or firm A may be over therelevant utilization threshold.

In step 408 the derivative product order is processed in a mannerdetermined by the derivative product order risk data and the utilizationdata. If the execution of the trade would not cause the resultingutilization data to exceed the relevant utilization threshold, the tradeis executed. There are several alternatives for treating orders thatwould cause the utilization data to exceed a relevant utilizationthreshold value. In a first embodiment a portion of the derivativeproduct order is executed. The portion includes the maximum number ofcontracts that do not cause the utilization data to exceed the thresholdvalue. In an alternative embodiment, a portion of the order thatincludes the minimum number of contracts that cause the utilization datato exceed the threshold value is executed. For example, if fourcontracts would not cause the utilization data to exceed the thresholdvalue and five contracts would, five contracts are executed. Of courseother embodiments may involve other trading units. For example, if acontract is typically traded in units of 100 contracts, each group of100 contracts would be treated as a trading unit and treated like theindividual contracts discussed above.

In another embodiment of the invention, an entire order is canceled ifthe order would result in a trader's order risk utilization stateexceeding the threshold value after the trade is executed. For example,if the execution of an order for five contracts would cause thethreshold value to be exceeded, no contracts are executed. In one morealternative embodiment, a derivative product order is executed as longas a trader's current order risk utilization state (before execution ofthe order) does not exceed the threshold value.

In step 410 it is determined whether the trader's order risk utilizationstate exceeds a threshold value. When a threshold has been exceeded,some or all of the trader's resting orders may be cancelled in step 412.In various embodiments all resting orders or all resting orders withinan option class are cancelled. Alternatively, all risk increasing ordersmay be cancelled. For example, if a positive delta limit has beenexceeded, then all call bids and put offers are cancelled. If a negativedelta limit has been exceeded, then all call offers and put bids arecancelled. If a positive gamma limit has been exceeded, then all calland put bids are cancelled. Likewise, if a negative gamma limit has beenexceeded, all call and put offers are cancelled.

Returning to FIG. 2, match system 206 may include modules that performsome or all of the functions of the modules shown in FIG. 1. Moreover,match system 206 may also be coupled to some or all of the elementsshown in FIG. 1. Match system 206 may also be configured to transmitwarning messages to traders alerting them of order risk utilizationstates. Match system 206 may also include or be coupled to an interfacethat allows traders to check current order risk utilization states viathe Internet, another network, telephone, etc.

FIG. 5 illustrates a variable defined derivative product order 500 inaccordance with an embodiment of the invention. Variable definedderivative product order 500 may include a field 502 for identifying atrader's account number. The underlying contract may be identified infield 504. The expiration month of the derivative product order may beidentified in field 506. The order may be identified as a put or a callin field 508 and whether the order is a buy or sell in field 510. Thequantity may be identified in field 512 and the strike price may beidentified in field 514. Delta, gamma, and vega values may be identifiedin fields 516, 518 and 520 respectively. Of course, other pricedetermination variables may also be identified as part of a standardvariable defined derivative product order.

A hedge transaction may be identified in field 522. The user may chooseto make the derivative product order contingent on the existence of anavailable hedge transaction by selecting radio button 524. The user mayalso choose to use best efforts to fill the hedge order after theexecution of the derivative product order by selecting radio button 526.

The formula for calculating the price of variable defined derivativeproduct order is identified in field 528. The trader can select astandard formula 530 to compute their derivative product price or selecta custom formula 532. In one embodiment, a standard formula is suppliedby or sponsored by an exchange. When a custom formula is selected, thetrader may also provide a formula in field 534 and the variables infield 536. In one implementation of the invention, variable definedderivative product order 500 is created in the form of an XML for HTMLdocument created by one of the computer devices shown in FIG. 1.Variable defined derivative product order 500 may be encrypted beforebeing transmitted to an exchange. Of course, one or more additional oralternative fields may be included. For example, a reference price maybe included to protect against mispricing conditions.

FIG. 6 illustrates a computer-implemented method of trading a derivativeproduct contract that involves the use of a variable order price, inaccordance with an embodiment of the invention. First, in step 602 it isdetermined whether the trader desires to use a standard exchangesponsored formula. When the trader uses a custom formula, the formula istransmitted to the exchange computer in step 604. Step 604 may alsoinclude the trader or exchange transmitting the formula to other marketparticipants. In step 606, the trader transmits price determinationvariable values for the standard formula to an exchange computer. Forexample, step 606 may include transmitting delta and gamma values to anexchange computer. Step 606 may also including transmitting a formulaand price determination variables to other computers so that othercomputers may calculate an order book. Alternatively, the exchangecomputer may distribute all formulas and price determination variablesto user computers. In step 608 the trader receives underlying data. Theunderlying data may include current bid and offer prices for underlyingput and call futures contracts.

In step 610 it is determined whether the underlying data has changed.The price of an underlying contract may change multiple times persecond. When the underlying contract data has changed, in step 612 thetrader's computer device may recalculate the order price of theirvariable defined derivative product order and all other variable definedderivative product orders from other users based on current data. Instep 614, it is determined whether any of the price determinationvariables used in the formula to calculate the order price have changed.The price determination variables may include delta, gamma, and vega.When the price determination variables have changed, in step 612, theorder price is recalculated. Of course, step 612 may be performed basedon changes in current underlying contract data and variables. The orderprice may be displayed to the trader or plotted on a graph that tracksorder prices.

Some of the advantages of aspects of the present invention are that theyallow traders to maintain an order book and limit the amount ofinformation that must be disseminated by an exchange computer or matchsystem. In particular, an exchange computer or match system may transmita plurality of variable defined derivative product orders to severaldifferent traders only when other derivative product order usersestablish their initial positions. Thereafter, the exchange computer maythen only transmit underlying data or other data used to calculatevariable defined derivative product order prices. Each trader computermay then periodically calculate current order prices based oninformation received from the exchange computer. For example, in step616 it is determined whether other variable defined derivative productorders are received. When variable defined derivative product orders arereceived, in step 618 the trader computer may calculate new order booklistings for current bids and offers related to variable definedderivative product based orders. The order book may be displayed to thetrader in any one of a variety of conventional formats. After step 618,control returns to step 608.

FIG. 7 illustrates a front-end system that may be used to manage risksassociated with derivative product orders placed at a plurality ofexchanges, in accordance with an embodiment of the invention. Afront-end order risk module 702 may reside on a terminal connected toone or more exchanges via a network, such as the Internet. Front-endorder risk module 702 may comprise a portion of a software applicationthat allows traders to interact with exchanges. A calculation module 704functions in a manner similar to calculation module 306. Front-end orderrisk module 702 allows traders to manage risks associated with restingorders placed at a plurality of exchanges. For example, the trader mayprovide order risk data to exchanges 706 and 708. An order risk datadatabase 710 may be included to calculate and track order risk data thathas been provided to exchange 706 and exchange 708.

An offset module 712 may be used to distribute risks among two or moreexchanges. For example, the current utilization of an order riskparameter at exchange 706 is equal to the utilization threshold. As aresult, no additional contracts will be executed at exchange 706.However, the current utilization of the order risk parameter at exchange708 is below the utilization threshold. Based on this information,offset module 712 may transmit offset value 714 to exchange 706 to allowexchange 706 to execute additional contracts. The use of offset 714allows the trader to continue conducting transactions while ensuringthat the combined utilization threshold is not exceeded. In oneembodiment of the invention, front-end order risk module 702 prompts thetrader to enter offset values. In another embodiment of the invention,offset module 712 includes computer-executable instructions thatgenerate offset values to transmit to exchanges based on the currentutilization at the relevant exchanges.

The present invention has been described herein with reference tospecific exemplary embodiments thereof. It will be apparent to thoseskilled in the art, that a person understanding this invention mayconceive of changes or other embodiments or variations, which utilizethe principles of this invention without departing from the broaderspirit and scope of the invention as set forth in the appended claims.All are considered within the sphere, spirit, and scope of theinvention. For example, aspects of the invention are not limit toimplementations that involve the trading of derivative products. Thoseskilled in the art will appreciate that aspects of the invention may beused in other markets. Credit market transactions, for example, involverisk parameters in the form of duration risk and default risks. Theprocessing of appropriate orders in credit markets may include analyzingduration risk utilization and default risk utilization.

What is claimed is:
 1. A computer-implemented method comprising:determining, by a processor, a first current utilization state for thefirst related trading entity; determining, by a processor, a secondcurrent utilization state for the second related trading entity;determining, by a processor, a combined current utilization state basedon the first and second current utilization states; and determining, bya processor, whether to permit execution of a trade based on thecombined current utilization state and a combined threshold that is afunction of a first threshold for a first of the related tradingentities and a second threshold for a second of the related tradingentities.
 2. The method of claim 1, wherein the first related tradingentity is subordinate to the second related trading entity.
 3. Themethod of claim 1, wherein the trade is permitted to execute in responseto determining that the combined current utilization state does notexceed the combined threshold.
 4. The method of claim 3, wherein thetrade is permitted to execute in response to determining that the firstcurrent utilization state does not exceed the first threshold.
 5. Themethod of claim 3, further comprising causing execution of the tradebased on the financial product order in response to being permitted. 6.The method of claim 1, wherein the trade is not permitted to execute inresponse to determining that the combined current utilization stateexceeds the combined threshold.
 7. The method of claim 1, wherein thefinancial product order comprises a hedge transaction.
 8. The method ofclaim 7, further comprising determining the combined current utilizationstate accounting for the hedge transaction.
 9. The method of claim 1,wherein the combined current utilization state includes utilization datafor the financial product order.
 10. The method of claim 1, wherein thedetermining of whether to permit execution of the trade furthercomprises preventing execution of the trade if the first currentutilization state exceeds the first threshold.
 11. A non-transitorycomputer readable medium storing computer executable instructions that,when executed, cause an apparatus at least to perform: determining afirst current utilization state for the first related trading entity;determining a second current utilization state for the second relatedtrading entity; determining a combined current utilization state basedon the first and second current utilization states; and determiningwhether to permit execution of a trade specified in the financialproduct order based on the combined current utilization state and acombined threshold is a function of a first threshold for a first of therelated trading entities and a second threshold for a second of therelated trading entities.
 12. The computer readable medium of claim 11,wherein the first related trading entity is subordinate to the secondrelated trading entity.
 13. The computer readable medium of claim 11,wherein the trade is permitted to execute in response to determiningthat the combined current utilization state does not exceed the combinedthreshold.
 14. The computer readable medium of claim 13, wherein thetrade is permitted to execute in response to determining that the firstcurrent utilization state does not exceed the first threshold.
 15. Thecomputer readable medium of claim 13, wherein the computer executableinstructions, when executed, cause the apparatus to cause execution ofthe trade based on the financial product order in response to beingpermitted.
 16. The computer readable medium of claim 11, wherein thetrade is not permitted to execute in response to determining that thecombined current utilization state exceeds the combined threshold. 17.The computer readable medium of claim 11, wherein the financial productorder comprises a hedge transaction.
 18. The computer readable medium ofclaim 17, wherein the computer executable instructions, when executed,cause the apparatus to determine the combined current utilization stateaccounting for the hedge transaction.
 19. The computer readable mediumof claim 11, wherein the combined current utilization state includesutilization data for the financial product order.
 20. The computerreadable medium of claim 11, wherein the determining of whether topermit execution of the trade further comprises preventing execution ofthe trade if the first current utilization state exceeds the firstthreshold.